<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
	<head profile="http://www.webdevout.net/profile/1.5/">
		<title>Beware of XHTML</title>
		<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
		<meta http-equiv="Content-Script-Type" content="text/javascript">
		<meta name="author" content="David Hammond">
		<meta name="description" content="An explanation of why XHTML may be a poor choice of document format in most cases.">
		<meta name="keywords" content="web design,web browsers,xhtml,html">
		<link rel="stylesheet" href="/style/basic.css" type="text/css">
		<link rel="stylesheet" href="/style/highlight/basic.css" type="text/css">
		<!--[if lt IE 8]> <link rel="stylesheet" href="/style/ie.css" type="text/css"> <![endif]-->
		<!--[if lt IE 7]> <link rel="stylesheet" href="/style/style.css?s=basic&amp;f=%2Farticles%2Fbeware-of-xhtml&amp;nobefore&amp;noalpha&amp;ie" type="text/css"> <![endif]-->
		<!--[if IE 7]> <link rel="stylesheet" href="/style/style.css?s=basic&amp;f=%2Farticles%2Fbeware-of-xhtml&amp;nobefore&amp;ie" type="text/css"> <![endif]-->
		<!--[if !lt IE 8]><![IGNORE[--><![IGNORE[]]>
		<link rel="stylesheet" href="/style/style.css?s=basic&amp;f=%2Farticles%2Fbeware-of-xhtml" type="text/css" title="Basic">
		<link rel="alternate stylesheet" href="/style/style.css?s=large&amp;f=%2Farticles%2Fbeware-of-xhtml" type="text/css" title="Large">
		<link rel="alternate stylesheet" href="/style/style.css?s=mono&amp;f=%2Farticles%2Fbeware-of-xhtml" type="text/css" title="Monochrome">
		<!--<![endif]-->
		<link rel="stylesheet" href="/style/print.css" type="text/css" media="print">
		<link rel="icon" href="/favicon.ico" type="image/x-icon">
		<link rel="icon" href="/favicon.png" type="image/png">
		<link rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/" title="Creative Commons license">
	</head>
	<body class="article">
		<p id="tophomelink"><a href="/">Back to Web Devout home</a></p>
		<h1>Beware of XHTML</h1>
		
		<p>If you're a web developer, you've probably worked a lot with <abbr title="eXtensible HyperText Markup Language">XHTML</abbr>, the markup language developed in 1999 to implement HTML as an XML format. Most people who use and promote XHTML do so because they think it's the &ldquo;next version&rdquo; of HTML, and they may have heard of some benefits here and there. But there is a lot more to it than you may realize, and if you're using it on your website, <strong>even if it validates</strong>, you are probably using it incorrectly.</p>
		<p>I believe that XHTML has many good potential applications, and I hope it continues to thrive as a standard. This is precisely why I have written this article. The state of XHTML on the Web today is more broken than the state of HTML, and most people don't realize because the major browsers are using classic HTML parsers that hide the problems. Even among the few sites that know how to trigger the XML parser, the authors tend to overlook some important issues. If you really hope for the XHTML standard to succeed, you should read this article carefully.</p>
		
		<div id="contents">
			<h2>Table of Contents</h2>
			<ol>
				<li><a href="#what_is_xhtml">What is XHTML?</a></li>
				<li><a href="#myths">Myths of XHTML</a></li>
				<li><a href="#benefits">Benefits of XML</a></li>
				<li><a href="#content_type">Content type is everything</a></li>
				<li><a href="#html_compatibility">HTML compatibility guidelines</a></li>
				<li><a href="#ie">Internet Explorer incompatibility</a></li>
				<li><a href="#content_negotiation">Content negotiation</a></li>
				<li><a href="#net">Null End Tags (NET)</a></li>
				<li><a href="#other">Firefox and other problems</a></li>
				<li><a href="#conclusion">Conclusion</a></li>
				<li><a href="#quotes">Quotes</a></li>
				<li><a href="#broken_xhtml">List of standards-related sites that break as XHTML</a></li>
				<li><a href="#html_sites">List of standards-related sites that stick with HTML</a></li>
				<li><a href="#related">Related sites</a></li>
				<li><a href="#see_also">See also</a></li>
			</ol>
		</div>
		
		<div id="what_is_xhtml">
			<h2>What is XHTML?</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>XHTML is a markup language originally hoped to someday replace HTML on the Web. For the most part, an XHTML 1.0 document differs from an HTML 4.01 document only in the lexical and syntactic rules: HTML is written in its own unique syntax defined by <abbr title="Standard Generalized Markup Language">SGML</abbr>, while XHTML is written in a different SGML-defined syntax called <abbr title="eXtensible Markup Language">XML</abbr>. The syntaxes differ in some of the characters that delimit tags and other constructs, whether or not certain types of shorthand markup may be used, and whether or not tag names or character entities are case sensitive, among other small differences.</p>
			<p>The Document Type Definition (DTD, which is referenced by the doctype declaration) then defines which elements, attributes, and character entities exist in the language and where those elements may be placed. The DTDs of XHTML 1.0 and HTML 4.01 are nearly identical, meaning that as far as things like elements and attributes go, XHTML 1.0 and HTML 4.01 are basically the same language. The only added benefit of XHTML is that it's written in XML and shares the benefits XML has over HTML's syntax. I'll explain those benefits later in this article, but first I'd like to debunk some of the <em>false benefits</em> you may have heard.</p>
		</div>
		
		<div id="myths">
			<h2>Myths of XHTML</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>There are many false benefits of XHTML promoted on the Web. Let's clear up some of them at a glance (with details and other pitfalls provided later):</p>
			
			<ul>
				<li>
					<p>XHTML does <em>not</em> promote separation of content and presentation any more than HTML does. XHTML has all of the same elements and attributes (including presentational ones) that HTML has, and it doesn't offer any additional CSS features. Semantic markup and separation of content and presentation is absolutely possible in HTML, and with equal ease. In terms of semantics, HTML 4.01 and XHTML 1.0 are exactly the same.</p>
				</li>
				
				<li>
					<p>Most XHTML pages on the Web are <em>not</em> parsed as XML by today's web browsers. With typical server configurations, browsers will parse your XHTML as HTML &ldquo;tag soup&rdquo; instead. The vast majority of XHTML pages on the Web <em>cannot</em> be parsed as XML since they rely on HTML error handling. Even most of the valid XHTML results in disfigured pages when parsed as XML, since they were only tested in HTML-parsing browsers.</p>
				</li>
				
				<li>
					<p>XML parsers do <em>not</em> typically check documents for validity. They only check them for well-formedness, which is a separate concept. If you leave out a required element, use deprecated or nonstandard elements or attributes, or put an element somewhere it isn't allowed, the XML parser will provide no indication of the error, and the browser will have to silently deal with the error like HTML parsers do.</p>
				</li>
				
				<li>
					<p>HTML is <em>not</em> deprecated and is <em>not</em> being phased out at this time. In fact, the World Wide Web Consortium recently <a href="http://www.w3.org/2006/11/HTML-WG-charter.html" class="external">renewed the HTML working group</a>, which is working to develop HTML 5. The developers of Firefox, Opera, and Safari have pushed very hard for the development of HTML 5 and have largely ignored the development of XHTML 2. The Safari development team has even <a href="http://webkit.org/blog/89/html-standards-process-returning-from-the-grave/" class="external">opted</a> to not take part in the XHTML 2 development process. The CTO of Opera said in an <a href="http://www.heise.de/ct/Redaktion/heb/w3c/lie_english.html" class="external">interview</a>, &ldquo;<span class="quote">I don't think XHTML is a realistic option for the masses. HTML5 is it.</span>&rdquo;</p>
				</li>
				
				<li>
					<p>XHTML 1.x is <em>not</em> &ldquo;future-compatible&rdquo;. XHTML 2, currently in the drafting stages, is not backwards-compatible with XHTML 1.x. XHTML 2 will have lots of major changes to the way documents are written and structured, and even if you already have your site written in XHTML 1.1, a complete site rewrite will usually be necessary in order to convert it to proper XHTML 2. A simple XSL transformation will <em>not</em> be sufficient in most cases, because some semantics won't translate properly.</p>
					<p>HTML 4.01 is actually more future-compatible. A valid HTML 4.01 document written to modern support levels will be valid HTML 5, and HTML 5 is where the majority of attention is from browser developers and the W3C.</p>
				</li>
				
				<li>
					<p>XHTML does <em>not</em> have good browser support. In typical setups, most browsers simply pretend that your XHTML pages are regular HTML (which presents a number of problems, as I'll explain later). Some major browsers like Firefox, Opera, and Safari may attempt to handle the page as proper XHTML if and only if you include a special HTTP header instructing it to do so. But when you do, Internet Explorer and a number of other user agents will choke on it and won't display a page at all. Even when handled as XHTML, the supporting browsers have a number of additional bugs, which I'll also discuss in this article.</p>
				</li>
				
				<li>
					<p>Most browsers do <em>not</em> parse valid XHTML dramatically faster than valid HTML, even when they're parsing XHTML correctly. This is partly because most browsers only support a small subset of the HTML/SGML standard to begin with, so the real complexities of proper HTML parsing are mostly ignored anyway. The only major additional complexity of HTML that is well supported is tag omission, but most browsers use hardcoded rules specific to HTML in order to cheat through that with minimal performance impact. The browser can lose some minor shorthand logic with XML, but it now has to use extra logic to confirm that the document is well-formed. Although XHTML, when parsed with an XML parser, may be slightly faster to parse than typical HTML, the difference isn't very significant in most cases. And either way, download speed is usually the bottleneck when it comes to document parsing. Whether it's HTML or XHTML, by the time the page finishes downloading, the whole thing is already parsed. The users won't notice any speed difference.</p>
				</li>
				
				<li>
					<p>XHTML is <em>not</em> extensible if you hope to support Internet Explorer or the number of other user agents that can't parse XHTML as XML. They will handle the document as HTML and you will have no extensibility benefit.</p>
				</li>
				
				<li>
					<p>XHTML source is <em>not</em> necessarily any &ldquo;cleaner&rdquo; than HTML source. If you prefer using lower-case tag and attribute names, you can do so in HTML. If you prefer having quotes around all attribute values, you may do so in HTML. If you prefer making sure all of your non-empty elements have end tags, you may use end tags in HTML, too. In fact, these are considered best practice principles in HTML. The only real markup differences between an HTML document following best practices and an XHTML document following the legacy compatibility guidelines are the doctype choice, XHTML's extra required attributes on the <code class="markup tag-name">html</code> tag, and XHTML's extra <code class="markup fragment">/</code> character in empty element tags.</p>
					<p>Some argue that the availability of HTML's shorthand constructs is what makes HTML &ldquo;unclean&rdquo;. But the only HTML shorthand construct that is required is the omitted end tag on elements that have to be empty, and it's common practice in XHTML (alas, even required in many cases) to also use a shorthand construct on those elements: the so-called &ldquo;self-closing tag&rdquo; which originates from SGML's &ldquo;null end tag&rdquo; shorthand construct.</p>
					<p>If you prefer to minimize your use of shorthand markup and would like the validator to enforce those restrictions in HTML as well, you can use Web Devout's <a href="/test?html4-good-practice">HTML Good Practice Checker</a>.</p>
				</li>
				
				<li>
					<p>Using XHTML does <em>not</em> encourage better support by web browsers and it is <em>not</em> &ldquo;a vote for a better Web&rdquo; if you are still supporting Internet Explorer and various search engines and other user agents that require <code class="content-type">text/html</code>. If you serve it with the typical <code class="content-type">text/html</code> content type, you are giving all browsers a thumbs-up to treat it exactly like classic HTML, meaning absolutely no progress is made. Even if you use only <code class="content-type">application/xhtml+xml</code> and shut out Internet Explorer and various other user agents entirely, it won't mean anything: Microsoft already plans to support real XHTML in an upcoming release of Internet Explorer; they just want to make sure they support it correctly from the initial launch. Even still, XHTML 1.x is a dead-end standard, since it's completely incompatible with XHTML 2.0 and all other future HTML/XHTML standards, as explained aboved, and since the majority of XHTML content on the Web today cannot be safely parsed as XML.</p>
				</li>
			</ul>
		</div>
		
		<div id="benefits">
			<h2>Benefits of XML</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>XML does have a number of improvements over HTML's syntax:</p>
			
			<ul>
				<li>
					<p>Although HTML's syntax allowed for a lot of shorthand markup and other flexibility, it proved too difficult to write a correct and fully-featured parser for it, since a truly correct parser would have to support the entire SGML standard. As a result, most user agents, including all of today's major web browsers, make many technically unsound assumptions about the lexical format of HTML documents and don't support a number of shorthand features like <a href="#net">Null End Tags</a> (<code class="markup fragment">&lt;tag/Content/</code>), unclosed start/end tags (<code class="markup fragment">&lt;tag&lt;tag&gt;</code>), and empty tags (<code class="markup fragment">&lt;&gt;</code>). XML was designed to eliminate these extra features and restrict documents to a tight set of rules that are more straight-forward for user agents to implement. In effect, XML defines the assumptions that user agents are allowed to make, while still resulting in a file that a theoretical fully-featured SGML user agent could parse once pointed to <a href="http://www.w3.org/TR/xhtml1/DTD/xhtml1.dcl" type="text/plain" class="external">XML's SGML declaration</a>.</p>
					<p>It should be noted that an XML parser for the most part is <em>not</em> dramatically easier to write than the level of HTML support offered by most HTML parsers (which will be thoroughly specified in HTML 5). Most of the features that would make HTML more difficult to write a parser for, such as custom SGML declarations, additional marked sections, and most of the shorthand constructs, have negligible use on the Web anyway and generally have poor or absent support in major web browsers. The most significant difference is XML's lack of support for omitted start and end tags, which in theory could amount to complicated logic in HTML for elements not defined as empty. Even still, most browsers don't bother to implement real DTD-based parsing logic, so it isn't quite so complicated in practice.</p>
				</li>
				
				<li>
					<p>In hopes of eliminating some error handling logic, XML user agents are told to not be flexible with errors: if a user agent comes upon a problem in the XML document, it will simply give up trying to read it. Instead, the user will be presented with a &ldquo;parse error&rdquo; message instead of the webpage. This eliminates the compatibility issues with incorrectly-written markup and browser-specific error handling methods by requiring documents to be &ldquo;well-formed&rdquo;, while giving webpage authors immediate indication of the problem. This does, however, mean that a single minor issue like an unescaped ampersand (<code>&amp;</code>) in a URL or a <a href="http://diveintomark.org/archives/2004/01/14/thought_experiment" class="external">mismatched character encoding in a trackback message</a> would cause the entire page to fail, and so most of today's public web applications can't safely be incorporated in a true XHTML page.</p>
					<p>While user agents are supposed to fail on any page that isn't well-formed (in other words, one that doesn't follow the generic XML grammar rules), they do not have to fail on a page that is well-formed but invalid. For example, although it is invalid to have a <code class="markup tag-name">span</code> element as an immediate child of the <code class="markup tag-name">body</code> element, most XML-supporting web browsers won't provide indication of the error because the page is still well-formed &mdash; that is, the DTD is violated, but not the fundamental rules of XML itself. Some user agents may choose to be &ldquo;validating&rdquo; agents and will also fail on validity errors, but they aren't common. There is some worry that people may rely too heavily on the well-formedness checker and forget to also check for validity, which could lead to a higher occurrence of invalid pages even among the otherwise standards-conscious developers.</p>
					<p>Despite popular assumption, even if an XML page is perfectly valid according to some validators, it still <a href="/articles/validity-and-well-formedness">might not be well-formed</a>. Well-formedness involves some requirements not present in the classic SGML definition of validity.</p>
				</li>
				
				<li>
					<p>Unlike HTML's SGML-defined syntax, which was specifically made for HTML, XML is a common syntax used in many different languages. This means that a single relatively simple set of parsing logic can handle a number of different languages. It also paved the way for the <a href="http://www.w3.org/TR/REC-xml-names/" class="external">Namespaces in XML</a> standard, which allows multiple documents in different XML formats to be combined in a single XML document, so that you can have, for example, an XHTML page that contains one or more SVG images that use MathML inside them.</p>
					<p>The practicality of this on webpages is a subject of debate. Separation of content, presentation, and behavior is a defining characteristic of modern web development, as the modular setup provides many benefits over the mixed alternative. Those benefits also hold true when debating the idea of mixed XML formats. Since (X)HTML provides facilities for embedding other XML formats in a more modular fashion (using elements like <code class="markup tag-name">object</code> and <code class="markup tag-name">link</code>), it's usually better to use the modular approach rather than mixing the files in a single document. Moving the SVG or RSS data into files separate from the (X)HTML allows the user agent to cache them and improve performance while reducing bandwidth cost and easing maintainability.</p>
				</li>
			</ul>
		</div>
		
		<div id="content_type">
			<h2>Content type is everything</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>When your website sends a document to the visitor's browser, it adds on a special content type header that lets the browser know what kind of document it's dealing with. For example, a PNG image has the content type <code class="content-type">image/png</code> and a CSS file has the content type <code class="content-type">text/css</code>. HTML documents have the content type <code class="content-type">text/html</code>. Web servers typically send this content type whenever the file extension is <code class="filename">.html</code>, and server-side scripting languages like PHP also typically send documents as <code class="content-type">text/html</code> by default.</p>
			<p>XHTML does <strong>not</strong> have the same content type as HTML. The proper content type for XHTML is <code class="content-type">application/xhtml+xml</code>. Currently, many web servers don't have this content type reserved for any file extension, so you would need to modify the server configuration files or use a server-side scripting language to send the header manually. Simply specifying the content type in a <code class="markup tag-name">meta</code> element will not work over HTTP.</p>
			<p>When a web browser sees the <code class="content-type">text/html</code> content type, regardless of what the doctype says, it automatically assumes that it's dealing with plain old HTML. Therefore, rather than using the XML parsing engine, it treats the document like tag soup, expecting HTML content. Because HTML 4.01 and simple XHTML 1.0 are often very similar, the browser can still understand the page fairly well. Most major browsers consider things like the self-closing portion of a tag (as in <code class="markup fragment">&lt;br /&gt;</code>) as a simple HTML error and strip it out, usually ending up with the HTML equivalent of what the author intended.</p>
			<p>However, when the document is treated like HTML, you get none of the benefits XHTML offers. The browser won't understand other XML formats like MathML and SVG that are included in the document, and it won't do the automatic validation that XML parsers do. In order for the document to be treated properly, the server would need to send the <code class="content-type">application/xhtml+xml</code> content type.</p>
			<p>The problems go deeper. Comment markers are sometimes handled differently depending on the content type, and when you enclose the contents of a <code class="markup element">script</code> or <code class="markup element">style</code> element with basic SGML-style comments, it will cause your script and style information to be completely ignored when the document is treated like XML. Also, any special markup characters used in the inline contents of a <code class="markup element">style</code> or <code class="markup element">script</code> element will be parsed as markup instead of being treated as character data like in HTML. To solve these problems, you must use an elaborate escape sequence described in the article <a href="/articles/escaping-style-and-script-data">Escaping Style and Script Data</a>, and even then there are situations in which it won't work.</p>
			<p>Furthermore, the CSS and DOM specifications have special provisions for HTML that don't apply to XHTML when it's treated as XML, so your page may look and behave in unexpected ways. The most common problem is a white gap around your page if you have a background on the <code class="markup element">body</code>, no background on the <code class="markup element">html</code> element, and any kind of spacing between the elements, such as a <code class="style property">margin</code>, <code class="style property">padding</code>, or a <code class="markup element">body</code> <code class="style property">height</code> under <code class="style value">100%</code> (browsers typically have some combination of these by default). In scripting, tag names are returned differently and <code class="script fragment">document.write()</code> doesn't work in XHTML treated as XML. Table structure in the DOM is different between the two parsing modes. These are only a select few of the many differences.</p>
			<p id="examples">The following are some examples of differing behavior between XHTML treated as HTML and XHTML treated as XML. The anticipated results are based on the way Internet Explorer, Firefox, and Opera treat XHTML served as HTML. Some other browsers are known to behave differently. Also note that Internet Explorer doesn't recognize the <code class="content-type">application/xhtml+xml</code> content type (see below for an explanation), so it will not be able to view the examples in the second column.</p>
			
			<table summary="Examples of differences between XHTML sent as &ldquo;text/html&rdquo; and &ldquo;application/xhtml+xml&rdquo;" class="cols2">
				<caption>Differences in XHTML handling</caption>
				
				<thead>
					<tr>
						<th scope="col">text/html</th>
						<th scope="col">application/xhtml+xml</th>
					</tr>
				</thead>
				
				<tbody>
					<tr>
						<td><a href="beware-of-xhtml-examples/1.html" type="text/html">Example 1</a></td>
						<td><a href="beware-of-xhtml-examples/1.xhtml" type="application/xhtml+xml">Example 1</a></td>
					</tr>
					<tr>
						<td><a href="beware-of-xhtml-examples/2.html" type="text/html">Example 2</a></td>
						<td><a href="beware-of-xhtml-examples/2.xhtml" type="application/xhtml+xml">Example 2</a></td>
					</tr>
					<tr>
						<td><a href="beware-of-xhtml-examples/3.html" type="text/html">Example 3</a></td>
						<td><a href="beware-of-xhtml-examples/3.xhtml" type="application/xhtml+xml">Example 3</a></td>
					</tr>
					<tr>
						<td><a href="beware-of-xhtml-examples/4.html" type="text/html">Example 4</a></td>
						<td><a href="beware-of-xhtml-examples/4.xhtml" type="application/xhtml+xml">Example 4</a></td>
					</tr>
					<tr>
						<td><a href="beware-of-xhtml-examples/5.html" type="text/html">Example 5</a></td>
						<td><a href="beware-of-xhtml-examples/5.xhtml" type="application/xhtml+xml">Example 5</a></td>
					</tr>
					<tr>
						<td><a href="beware-of-xhtml-examples/6.html" type="text/html">Example 6</a></td>
						<td><a href="beware-of-xhtml-examples/6.xhtml" type="application/xhtml+xml">Example 6</a></td>
					</tr>
					<tr>
						<td><a href="beware-of-xhtml-examples/7.html" type="text/html">Example 7</a></td>
						<td><a href="beware-of-xhtml-examples/7.xhtml" type="application/xhtml+xml">Example 7</a></td>
					</tr>
					<tr>
						<td><a href="beware-of-xhtml-examples/8.html" type="text/html">Example 8</a></td>
						<td><a href="beware-of-xhtml-examples/8.xhtml" type="application/xhtml+xml">Example 8</a></td>
					</tr>
					<tr>
						<td><a href="beware-of-xhtml-examples/9.html" type="text/html">Example 9</a></td>
						<td><a href="beware-of-xhtml-examples/9.xhtml" type="application/xhtml+xml">Example 9</a></td>
					</tr>
				</tbody>
			</table>
		</div>
		
		<div id="html_compatibility">
			<h2>HTML compatibility guidelines</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>When the XHTML 1.0 specification was first written, there were provisions that allowed an XHTML document to be sent as <code class="content-type">text/html</code> as long as certain compatibility guidelines were followed. The idea was to ease migration to the new format without breaking old user agents. However, these provisions are now viewed by many as a mistake. The whole point of XHTML is to be an XML alternative to HTML, yet due to the allowance of XHTML documents to be sent as <code class="content-type">text/html</code>, most so-called XHTML documents on the Web today would break if they were treated like XML (see the <a href="#broken_xhtml">real-world examples below</a>). This even includes many valid XHTML documents. Several prominent members of the W3C are now challenging the wisdom of the <code class="content-type">text/html</code> provisions and advocating that this content type should never be allowed for XHTML.</p>
			<p>Many authors incorrectly believe that following the HTML compatibility guidelines and validating the document will guarantee that the document is compatible with both the HTML and XHTML specifications. In reality, if you use even a single self-closing tag in the document (which includes any <code class="markup tag-name">link</code>, <code class="markup tag-name">img</code>, or <code class="markup tag-name">br</code> tag), you are already creating incompatibilities between the two specifications. The reason for this particular issue is explained <a href="#net">below</a>. In this article, I have already explained a number of other factors not covered in XHTML 1.0 Appendix C that will also cause the document to run into incompatibilities. The truth is that the HTML compatibility guidelines do not actually provide true compatibility between HTML and XHTML; they merely attempt to minimize the damage of using <code class="content-type">text/html</code> for XHTML documents, and that damage control is very limited in effectiveness.</p>
			<p>XHTML 1.x already makes no provision for the use of <code class="content-type">text/html</code> when taking advantage of any XHTML features not present in HTML, and the current draft of XHTML 2 expressly forbids it.</p>
		</div>
		
		<div id="ie">
			<h2>Internet Explorer incompatibility</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>Internet Explorer does not support XHTML. Like other web browsers, when a document is sent as <code class="content-type">text/html</code>, it treats the document as if it was a poorly constructed HTML document. However, when the document is sent as <code class="content-type">application/xhtml+xml</code>, Internet Explorer won't recognize it as a webpage; instead, it will simply present the user with a download dialog. This issue still exists in Internet Explorer 7.</p>
			<p>Although all other major web browsers, including Firefox, Opera, Safari, and Konqueror, support XHTML, the lack of support in Internet Explorer as well as major search engines and web applications makes use of it very discouraged.</p>
		</div>
		
		<div id="content_negotiation">
			<h2>Content negotiation</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>Content negotiation is the idea of sending different content depending on what the user agent supports. Many sites attempt to send XHTML as <code class="content-type">application/xhtml+xml</code> to those who support it, and either XHTML as <code class="content-type">text/html</code> or real HTML to those who don't.</p>
			<p>There are two methods generally used to determine what the user agent supports, using the <code class="http header">Accept</code> HTTP header: most often, sites use the incorrect method where they simply look for the string &ldquo;<code class="content-type">application/xhtml+xml</code>&rdquo; in the header value; although some sites will use the correct method, where they actually parse the header value, supporting wildcards and ordering by <var>q</var> value.</p>
			<p>Unfortunately, neither of these methods works reliably.</p>
			<p>The first method doesn't work because not all XHTML-supporting user agents actually have the text &ldquo;<code class="content-type">application/xhtml+xml</code>&rdquo; in the <code class="http header">Accept</code> header. Safari and Konqueror are two such browsers. The <code class="content-type">application/xhtml+xml</code> content type is implied by a wildcard value instead. Meanwhile, not all HTML-supporting user agents have &ldquo;<code class="content-type">text/html</code>&rdquo; in the header. Internet Explorer, for example, doesn't mention this content type. Like Safari and Konqueror, it implies this support by using a wildcard. Even among those user agents that support XHTML and mention <code class="content-type">application/xhtml+xml</code> in the header, it may have a lower <var>q</var> value than <code class="content-type">text/html</code> (or a matching wildcard), which implies that the user agent actually prefers <code class="content-type">text/html</code> (in other words, its XHTML support may be experimental or broken).</p>
			<p>The second method (the correct, 100% standards-complaint one) doesn't work because most major browsers have inaccurate <code class="http header">Accept</code> headers:</p>
			<ul>
				<li>Firefox 2 and below have <code class="content-type">application/xhtml+xml</code> listed with a higher <var>q</var> value than <code class="content-type">text/html</code>, even though Mozilla has posted an <a href="http://www.mozilla.org/docs/web-developer/faq.html#accept" class="external">official recommendation</a> on its site saying that websites should use <code class="content-type">text/html</code> for these versions if they can, for reasons described <a href="#other">below</a>.</li>
				<li>Internet Explorer doesn't list either <code class="content-type">text/html</code> or <code class="content-type">application/xhtml+xml</code> in its <code class="http header">Accept</code> header. Instead, both content types are covered by a single wildcard value (which implies that every content type in existence is supported equally well, which is obviously untrue). So Internet Explorer is saying that it supports both <code class="content-type">text/html</code> and <code class="content-type">application/xhtml+xml</code> equally, even though it actually doesn't support <code class="content-type">application/xhtml+xml</code> at all. In the case that a user agent claims to support both equally, the site is supposed to use its own preference. A possible workaround is for the site to &ldquo;prefer&rdquo; sending <code class="content-type">text/html</code> or, in a toss-up situation, only send <code class="content-type">application/xhtml+xml</code> if it's actually mentioned explicitly in the header. However...</li>
				<li>Safari and Konqueror, which support XHTML, also give <code class="content-type">text/html</code> and <code class="content-type">application/xhtml+xml</code> the same <var>q</var> value (in fact, like Internet Explorer, they also claim to support everything in existence equally well). But they don't mention <code class="content-type">application/xhtml+xml</code> explicitly &mdash; it's implied by a wildcard. So if you use the above workaround, Safari and Konqueror will receive <code class="content-type">text/html</code> even though they really do support <code class="content-type">application/xhtml+xml</code>.</li>
			</ul>
			<p>As disappointing as it may be, content negotiation simply isn't a reliable approach to this problem.</p>
		</div>
		
		<div id="net">
			<h2>Null End Tags (NET)</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>In XHTML, all elements are required to be closed, either by an end tag or by adding a slash to the start tag to make it self-closing. Since giving empty elements like <code class="markup element">img</code> or <code class="markup element">br</code> an end tag would confuse browsers treating the page like HTML, self-closing tags tend to be promoted. However, XML self-closing tags directly conflict with a little-known and poorly supported HTML/SGML feature: Null End Tags.</p>
			<p>A Null End Tag is a special shorthand form of a tag that allows you to save a few characters in the document. Instead of writing <code class="markup fragment">&lt;title&gt;My page&lt;/title&gt;</code>, you could simply write <code class="markup fragment">&lt;title/My page/</code> to accomplish the same thing. Due to the rules of Null End Tags, a single slash in an empty element's start tag would close the tag right then and there, meaning <code class="markup fragment">&lt;br/</code> is a complete and valid tag in HTML. As a result, if you have <code class="markup fragment">&lt;br/&gt;</code> or <code class="markup fragment">&lt;br /&gt;</code>, a browser supporting Null End Tags would see that as a <code class="markup element">br</code> element immediately followed by a simple <code class="markup character-data">&gt;</code> character. Therefore, an XHTML page treated as HTML could be littered with unwanted <samp>&gt;</samp> characters.</p>
			<p>This problem is often overlooked because most popular browsers today are lacking support for Null End Tags, as well as some other SGML shorthand features. However, there are still some smaller user agents that properly support Null End Tags. One of the more well-known user agents that support it is the <a href="http://validator.w3.org/" class="external">W3C validator</a>. If you send it a page that uses XHTML self-closing tags, but force it to parse the page as HTML/SGML like most user agents do for <code class="content-type">text/html</code> pages, you can see the results in the <a href="http://validator.w3.org/check?uri=http%3A%2F%2Fwww.webdevout.net%2Ftest%3Fvalidator-html-net-parsing%26raw&amp;ss=1&amp;outline=1#outlineresult" class="external">outline</a>: immediately after each of the self-closing elements, there is an unwanted <code class="markup chracter-data">&gt;</code> character that will be displayed on the page itself.</p>
			<p>(It should be noted that the W3C Validator is unusual in that it generally determines the parsing mode from the doctype, rather than from the content type as most other user agents do. Therefore, an HTML doctype was used in the above example just so the validator would attempt to parse the page using the HTML syntax as all major browsers will for <code class="content-type">text/html</code> pages regardless of the doctype. The Null End Tag rules are actually set in the SGML syntax definition, not the DTD, so this example is accurate to what you should expect in a fully compliant SGML user agent even with an XHTML doctype.)</p>
			<p>Technically, a restricted and altered form of Null End Tags exists in XML and is frequently used: the self-closing portion of the start tag. While Null End Tags are defined as <code class="markup fragment">/ <var>...</var> /</code> in HTML's syntax, they are specially defined as <code class="markup fragment">/ <var>...</var> &gt;</code> in XML with the added restriction that it must close immediately after it is opened, meaning the element must have no content. This was designed to look similar to a regular start tag for web developers who are unfamiliar with typical Null End Tags. However, in the process it creates inherent incompatibility with HTML's syntax for all empty elements.</p>
			<p>In summary, although this issue doesn't show in most popular web browsers, a user agent that more fully supports SGML would see unwanted <samp>&gt;</samp> characters all over XHTML pages that are sent with the <code class="content-type">text/html</code> content type. If the goal of using XHTML is to help promote standards, then it's quite counterproductive to cause unnecessary problems for user agents that more correctly comply to the SGML standard.</p>
		</div>
		
		<div id="other">
			<h2>Firefox and other problems</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>Although Firefox supports the parsing of XHTML documents as XML when sent with the <code class="content-type">application/xhtml+xml</code> content type, its performance in versions 2.0 and below is actually worse than with HTML. When parsing a page as HTML, Firefox will begin displaying the page while the content is being downloaded. This is called incremental rendering. However, when it's parsing XML content, Firefox 2.0 and below will wait until the entire page is downloaded and checked for well-formedness before any of the content is displayed. This means that, although in theory XML is supposed to be faster to parse than HTML, in reality these versions of Firefox usually display HTML content to the user much faster than XHTML/XML content. Thankfully, this issue is expected to be resolved in Firefox 3.0.</p>
			<p>However, there are also issues in other browsers, such as certain HTML-specific provisions in the CSS and DOM standards being mistakenly applied to XHTML content parsed as XML. For example, if there is a background set on the <code class="markup tag-name">body</code> element and none on the <code class="markup tag-name">html</code> element, Opera will apply the background to the <code class="markup tag-name">html</code> element as it would in HTML. So even when dealing exclusively with XHTML parsed as XML, you still run into a number of the same problems that you do when trying to serve XHTML either way.</p>
			<p>All in all, true XHTML support in major user agents is still very weak. Because a key user agent &mdash; namely, Internet Explorer &mdash; has made no visible effort to support XHTML, other major user agents have continued to see it as a relatively low priority and so these bugs have lingered. HTML is recommended over XHTML by both <a href="http://www.mozilla.org/docs/web-developer/faq.html#accept" class="external">Mozilla</a> and <a href="http://webkit.org/blog/?p=68" class="external">Safari</a> and is generally better supported than XHTML by all major browsers.</p>
		</div>
		
		<div id="conclusion">
			<h2>Conclusion</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>XHTML is a very good thing, and I certainly hope to see it gain widespread acceptance in the future. However, it simply isn't widely supported in its proper form. XHTML is an XML format, and to force a web browser to treat it like HTML is going against the whole purpose of XHTML and also inevitably causes other complications. Assuming you don't want to dramatically limit access to your information, XHTML can only be used incorrectly, be interpretted as invalid markup by most user agents, cause unwanted results in others, and offer no added benefit over HTML. HTML 4.01 Strict is still what most user agents and search engines are most accustomed to, and there's absolutely nothing wrong with using it if you don't need the added benefits of XML. HTML 4.01 is still a W3C Recommendation, and the W3C has even announced plans to <a href="http://dig.csail.mit.edu/breadcrumbs/node/166" class="external">further develop HTML</a> alongside XHTML in the future.</p>
		</div>
		
		<div id="quotes">
			<h2>Quotes</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<ul>
				<li><cite>Chris Wilson</cite>, long-time program manager and developer for the Internet Explorer platform at Microsoft, posted on the official Internet Explorer blog in September 2005 pointing out that Internet Explorer doesn't really support XHTML yet and why:
					
					<blockquote cite="http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx">
						<p>[I]f we tried to support real XHTML in IE 7 we would have ended up using our existing HTML parser (which is focused on compatibility) and hacking in XML constructs. It is highly unlikely we could support XHTML well in this way [...] I would much rather take the time to implement XHTML properly after IE 7, and have it be truly interoperable</p>
					</blockquote>
					
					<p class="quote-source"><cite><a href="http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx" class="external">Source</a></cite></p>
				</li>
				
				<li>The official <cite>Mozilla web developer FAQ</cite> states:
					
					<blockquote cite="http://www.mozilla.org/docs/web-developer/faq.html#accept">
						<p>Serving valid HTML 4.01 as text/html ensures the widest browser and search engine support.</p>
					</blockquote>
					
					<p class="quote-source"><cite><a href="http://www.mozilla.org/docs/web-developer/faq.html#accept" class="external">Source</a></cite></p>
				</li>
				
				<li><cite>Safari</cite> developer Maciej Stachowiak posted on the official Safari blog in September 2006:
					
					<blockquote cite="http://webkit.org/blog/?p=68">
						<p>On today's web, the best thing to do is to make your document HTML4 all the way. Full XHTML processing is not an option, so the best choice is to stick consistently with HTML4.</p>
					</blockquote>
					
					<p class="quote-source"><cite><a href="http://webkit.org/blog/?p=68" class="external">Source</a></cite></p>
				</li>
				
				<li><cite>H&aring;kon Wium Lie</cite>, CTO of Opera, member of the W3C, and the person who first proposed the language that became CSS, stated in a January 2007 interview:
					
					<blockquote cite="http://www.heise.de/ct/Redaktion/heb/w3c/lie_english.html">
						<p>I don't think XHTML is a realistic option for the masses. HTML5 is it.</p>
					</blockquote>
					
					<p class="quote-source"><cite><a href="http://www.heise.de/ct/Redaktion/heb/w3c/lie_english.html" class="external">Source</a></cite></p>
				</li>
				
				<li><cite>Anne van Kesteren</cite>, standards expert at Opera, posted in his blog in August 2004:
					
					<blockquote cite="http://annevankesteren.nl/2004/08/xhtml">
						<p>I'm an advocate of using XHTML only in the correct way, which basically means you have to use HTML. Period.</p>
					</blockquote>
					
					<p class="quote-source"><cite><a href="http://annevankesteren.nl/2004/08/xhtml" class="external">Source</a></cite></p>
				</li>
				
				<li><cite>Ian Hickson</cite>, a W3C member who has worked for both Opera and Mozilla, wrote and continues to maintain an article warning about the complications with using XHTML on public websites, concluding:
					
					<blockquote cite="http://www.hixie.ch/advocacy/xhtml">
						<p>Authors intending their work for public consumption should stick to HTML 4.01</p>
					</blockquote>
					
					<p class="quote-source"><cite><a href="http://www.hixie.ch/advocacy/xhtml" class="external">Source</a></cite></p>
				</li>
				
				<li><cite>Daniel Glazman</cite>, a W3C member who is currently working with Mozilla on an upcoming standards-based graphical webpage editor, stated in an interview with xhtml.com:
					
					<blockquote cite="http://xhtml.com/en/future/fixing-the-web-1/">
						<p>What we needed most is the acknowledgement that the Web is based on HTML 4, CSS, JavaScript and a few other technologies. That is now done, the W3C working on a successor to HTML 4 based on the work done by the WHAT-WG. XHTML 2 is not the future of the Web.</p>
					</blockquote>
					
					<p class="quote-source"><cite><a href="http://xhtml.com/en/future/fixing-the-web-1/" class="external">Source</a></cite></p>
				</li>
			</ul>
		</div>
		
		<div id="broken_xhtml">
			<h2>List of standards-related sites that break as XHTML</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>The following are just a few of the countless sites that use an XHTML doctype but, as of this moment of writing, completely fail to load or otherwise work improperly when parsed as XML, thus missing the whole point of XHTML. The authors of most of these sites are quite prominent in the web standards community &mdash; many are involved in the <a href="http://www.webstandards.org/" class="external">Web Standards Project (<acronym>WaSP</acronym>)</a> &mdash; yet they have still fallen victim to the pitfalls of current use of XHTML. In fact, I have found that <em>nearly all XHTML websites owned by WaSP members have problems when parsed as XML</em>.</p>
			<p>You could consider this a &ldquo;shame list&rdquo; of sorts. These are the same people who are supposed to be teaching others how to use web standards properly, yet they have written markup that basically depends on browsers treating it incorrectly. But the main point of this list isn't to pick on individuals; it's to reinforce the fact that even so-called experts at web standards have trouble juggling the different ways XHTML will inevitably be handled on the Web. And what benefit does it bring? <em>None of the following sites make use of anything XHTML offers over HTML.</em></p>
			<p>The following &ldquo;View as application/xhtml+xml&rdquo; links allow you to see how the pages would look when sent with the proper XHTML content type. This script adds a <code class="markup tag-name">base</code> element so that relative URLs work properly, but no other modifications are made to the markup. Alternatively, you can test the original unaltered page's XHTML rendering in Firefox using the <a href="https://addons.mozilla.org/firefox/3207/" class="external">Force Content-type</a> extension and setting the new content-type to <code class="content-type">application/xhtml+xml</code>.</p>
			<p>These links were last checked 2007-09-23.</p>
			
			<dl class="websites">
				<dt><a href="http://accessify.com/" class="external">Accessify</a> - <em>WaSP Steering Committee, Accessibility Task Force</em></dt>
					<dd>Displayed as generic XML, not interpretted as XHTML. The XML namespace was omitted.</dd>
					<dd><a href="/test?http%3A%2F%2Faccessify.com%2F&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://www.alistapart.com/" class="external">A List Apart</a> - <em>various WaSP members</em></dt>
					<dd>Brown gap below A List Apart logo (site relies on &ldquo;Almost Standards Mode&rdquo;, a mode in between Quirks Mode and Standards Mode that only exists for Transitional documents parsed as HTML). Ad and &ldquo;Job Board&rdquo; section don't appear, because they rely on an HTML-specific DOM method.</dd>
					<dd><a href="/test?http%3A%2F%2Fwww.alistapart.com%2F&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://allinthehead.com/" class="external">all in the &lt;head&gt;</a> - <em>WaSP Steering Committee</em></dt>
					<dd><strong>Page doesn't load.</strong> Not well-formed. (Note: this page is valid according to the XHTML DTD and XML's SGML-defined syntax, but XML has additional well-formedness rules that this page breaks, observed in the <a href="http://allinthehead.com/retro/303/textpattern-and-the-technorati-link-count-widget" class="external">Textpattern and the Technorati Link Count Widget</a> post. A similar <a href="/articles/validity-and-well-formedness-examples/2.xhtml">test case</a> is available.)</dd>
					<dd><a href="/test?http%3A%2F%2Fallinthehead.com%2Fretro%2F303%2Ftextpattern-and-the-technorati-link-count-widget&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://www.csszengarden.com/" class="external">CSS Zen Garden</a> - <em>WaSP</em></dt>
					<dd>Top background doesn't display. The page relies on HTML-specific background behavior. Numerous designs have errors with a similar cause.</dd>
					<dd><a href="/test?http%3A%2F%2Fwww.csszengarden.com%2F&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://dean.edwards.name/weblog/" class="external">dean.edwards.name/weblog/</a> - <em>WaSP DOM Scripting Task Force, Microsoft Task Force</em></dt>
					<dd>For browsers that support behavior binding (including Firefox) for the dynamic syntax highlighting of the code snippits, most of the code boxes fail to load the contents, resulting in many empty boxes where code snippits should be, or the code appears without syntax highlighting.</dd>
					<dd><a href="/test?http%3A%2F%2Fdean.edwards.name%2Fweblog%2F&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://westciv.typepad.com/dog_or_higher/" class="external">dog or higher</a></dt>
					<dd><strong>Page doesn't load.</strong> Not well-formed.</dd>
					<dd><a href="/test?http%3A%2F%2Fwestciv.typepad.com%2Fdog_or_higher%2F&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://www.ellythompson.co.uk/blog/" class="external">Elly Thompson's Weblog</a></dt>
					<dd><strong>Page doesn't load.</strong> Not well-formed.</dd>
					<dd><a href="/test?http%3A%2F%2Fwww.ellythompson.co.uk%2Fblog%2F&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://www.hm-ad.com/" class="external">holly marie</a> - <em>WaSP Steering Committee</em></dt>
					<dd>Thick white gap at top and bottom of the page. This page relies on HTML-specific background behavior.</dd>
					<dd><a href="/test?http%3A%2F%2Fwww.hm-ad.com%2F&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://www.veen.com/jeff/index.html" class="external">Jeffrey Veen</a> - <em>WaSP emeritus</em></dt>
					<dd><strong>Page doesn't load.</strong> Not well-formed.</dd>
					<dd><a href="/test?http%3A%2F%2Fwww.veen.com%2Fjeff%2Findex.html&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://blog.meriwilliams.com/" class="external">Meriblog</a></dt>
					<dd><strong>Page doesn't load.</strong> Not well-formed.</dd>
					<dd><a href="/test?http%3A%2F%2Fblog.meriwilliams.com%2F&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://mezzoblue.com/" class="external">mezzoblue</a> - <em>WaSP</em></dt>
					<dd>Displayed as generic XML, not interpretted as XHTML. The XML namespace was omitted. Also, <strong>individual post pages don't load.</strong> Not well-formed.</dd>
					<dd><a href="/test?http%3A%2F%2Fmezzoblue.com%2F&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://molly.com/" class="external">molly.com</a> - <em>WaSP Group Lead</em></dt>
					<dd><strong>Page doesn't load.</strong> Not well-formed. This error is in a post that's currently on the front page, so the front page will be viewable again once that post drops off. Aside from that error, Flickr and &ldquo;Elsewhere&rdquo; sections fail to load because the script contents are commented out or rely on HTML-specific DOM methods.</dd>
					<dd><a href="/test?http%3A%2F%2Fmolly.com%2F&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://www.vanderwal.net/random/index.php" class="external">Off the Top</a> - <em>WaSP Steering Committee</em></dt>
					<dd><strong>Page doesn't load.</strong> Not well-formed.</dd>
					<dd><a href="/test?http%3A%2F%2Fwww.vanderwal.net%2Frandom%2Findex.php&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
				
				<dt><a href="http://www.positioniseverything.net/" class="external">Position Is Everything</a></dt>
					<dd><strong>Page doesn't load.</strong> Not well-formed.</dd>
					<dd><a href="/test?http%3A%2F%2Fwww.positioniseverything.net%2F&amp;raw&amp;html_type=application/xhtml%2Bxml">View as application/xhtml+xml</a></dd>
			</dl>
		</div>
		
		<div id="html_sites">
			<h2>List of standards-related sites that stick with HTML</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>The following are some significant sites relevant to web standards that continue to use HTML rather than XHTML.</p>
			
			<ul>
				<li><a href="http://www.456bereastreet.com/" class="external">456 Berea Street</a></li>
				<li><a href="http://annevankesteren.nl/" class="external">Anne van Kesteren</a></li>
				<li><a href="http://bitesizestandards.com/" class="external">Bite Size Standards</a></li>
				<li><a href="http://dbaron.org/" class="external">David Baron's Homepage</a></li>
				<li><a href="http://ln.hixie.ch/" class="external">Hixie's Natural Log</a></li>
				<li><a href="http://www.snook.ca/jonathan/" class="external">Jonathan Snook's Blog</a></li>
				<li><a href="http://meyerweb.com/" class="external">meyerweb.com</a></li>
				<li><a href="http://www.webdevout.net/">Web Devout</a></li>
				<li><a href="http://webkit.org/" class="external">WebKit</a></li>
			</ul>
		</div>
		
		<div id="related">
			<h2>Related sites</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<p>The following are other websites that are related to this article.</p>
			<ul>
				<li><a href="http://blog.dorward.me.uk/2006/10/28/html-and-html.html" class="external">HTML is dead, long live HTML</a></li>
				<li><a href="http://www.wlmark.com/xhtml-html.php" class="external">html vs xhtml</a></li>
				<li><a href="http://www.spartanicus.utvinternet.ie/no-xhtml.htm" class="external">No to XHTML</a></li>
				<li><a href="http://annevankesteren.nl/2004/08/xhtml" class="external">Quick guide to XHTML</a></li>
				<li><a href="http://www.hixie.ch/advocacy/xhtml" type="text/plain" class="external">Sending XHTML as text/html Considered Harmful</a></li>
				<li><a href="http://turnipspatch.com/articles/that-little-xhtml-or-html-debate" class="external">That little &quot;XHTML or HTML?&quot; debate</a></li>
				<li><a href="http://fadtastic.net/2006/11/02/the-invisible-design-decision/" class="external">The Invisible Design Decision</a></li>
				<li><a href="http://diveintomark.org/archives/2004/01/14/thought_experiment" class="external">Thought experiment</a></li>
				<li><a href="http://webkit.org/blog/?p=68" class="external">Understanding HTML, XML and XHTML</a></li>
				<li><a href="http://www.elementary-group-standards.com/html/why-do-you-use-html-4.html" class="external">Why do You use HTML 4?</a></li>
				<li><a href="http://akaxaka.gameover.com/index.php/2006/why-i-use-html-instead-of-xhtml/" class="external">Why I use HTML (instead of xHTML)</a></li>
				<li><a href="http://www.benjaminhawkeslewis.com/www/web-design/why-not-xhtml" class="external">Why Not XHTML 1.0?</a></li>
				<li><a href="http://www.elementary-group-standards.com/archives/site-standards/why-xhtml.html" class="external">Why XHTML?</a></li>
				<li><a href="http://friendlybit.com/html/why-xhtml-is-a-bad-idea/" class="external">Why XHTML is a bad idea</a></li>
				<li><a href="http://www.autisticcuckoo.net/archive.php?id=2005/03/14/xhtml-is-dead" class="external">XHTML Is Dead</a></li>
				<li><a href="http://lachy.id.au/log/2005/12/xhtml-beginners" class="external">XHTML is not for Beginners</a></li>
				<li><a href="http://www.dev-archive.net/articles/xhtml.html" class="external">XHTML - myths and reality</a></li>
				<li><a href="http://www.sitepoint.com/forums/showthread.php?t=393445" class="external">XHTML vs HTML FAQ</a></li>
			</ul>
		</div>
		
		<div id="see_also">
			<h2>See also</h2>
			<a href="#contents" class="toplink">Up</a>
			
			<ul>
				<li><a href="/articles/escaping-style-and-script-data">Escaping style and script data</a></li>
				<li><a href="/articles/validity-and-well-formedness">Validity and well-formedness</a></li>
				<li>Tidings: <a href="/tidings/2006/08/09/null-end-tags-in-xhtml/">Null end tags in XHTML</a></li>
				<li>Tidings: <a href="/tidings/2006/04/16/the-problem-with-the-net/">The problem with the NET</a></li>
			</ul>
		</div>
		
		<hr>
		
		<div id="footer">
			
			<p class="homelink"><a href="/">&larr; <span>Back to Web Devout home</span></a></p>
			
			<p class="license">This work is copyright &copy; 2011 <a href="/david-hammond/">David Hammond</a> and is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/" class="external">Creative Commons Attribution Share-Alike License</a>. It may be copied, modified, and distributed freely as long as it attributes the original author and maintains the original license. See the license for details.</p>
			
			<ul class="site_info">
				<li class="first-child"><a href="/about">About Web Devout</a></li>
				<li><a href="/about#privacy">Privacy policy</a></li>
				<li><a href="/faq"><acronym title="Frequently Asked Questions">FAQ</acronym></a></li>
				<li><a href="/tidings/">Blog</a></li>
				<li><a href="http://groups.google.com/group/webdevout" class="external">Discussion</a></li>
				<li><a href="/search">Search</a></li>
				<li><a href="/contact">Contact me</a></li>
			</ul>
			
		</div>
		
		<!-- Google Analytics -->
		<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
		<script type="text/javascript">_uacct="UA-66500-2";urchinTracker();</script>
	</body>
</html>
